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Abstract — This paper introduces Prawn, a tool for rapid 
prototyping communication protocols over IEEE 802.11 networks. 
Prawn provides a software environment that makes prototyping 
as quick, easy, and effortless as possible and thus allows re- 
searchers to conduct both functional assessment and performance 
evaluation as an integral part of the protocol design process. 
Since Prawn runs on real IEEE 802.11 nodes, prototypes can 
be evaluated and adjusted under realistic conditions. Once the 
prototype has been extensively tested and thoroughly validated, 
and its functional design tuned accordingly, it is then ready 
for implementation. Prawn facilitates prototype development by 
providing: (i) a set of building blocks that implement common 
functions needed by a wide range of wireless protocols (e.g., 
neighbor discovery, link quality assessment, message transmission 
and reception), and (ii) an API that allows protocol designers to 
access Prawn primitives. We show through a number of case 
studies how Prawn supports prototyping as part of protocol 
design and, as a result of enabling deployment and testing under 
real-world scenarios, how Prawn provides useful feedback on 
protocol operation and performance. 
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Fig. 1: Bridging the gap between theory and practice in the 
design of protocols and systems for wireless networks. 



I. Introduction 

Designing protocols for wireless networks poses countless 
technical challenges due to a variety of factors such as 
node mobility, node heterogeneity, power limitations, and the 
fact that the characteristics of the wireless channel are non- 
deterministic and can be highly variant in space and time. This 
implies that testing and evaluating such protocols under real 
operating conditions is crucial to ensure adequate functionality 
and performance. 

In fact, the networking research community has already ac- 
knowledged the importance of testing and evaluating wireless 
protocol proposals under real- world conditions. As a result, 
over the last few years, a number of testbeds, such as Orbit [1], 
UnWiReD's testbed [2], Netbed [3], and Roofnet [4], [5], as 
well as implementation tools, such as Click [6] and XORP [7], 
have been developed to support the deployment and evaluation 
of wireless protocols under realistic scenarios. 

As illustrated in Figure la, there are mainly three evaluation 
methodologies commonly used when designing communica- 
tion systems, namely mathematical analysis, simulation, and 
emulation. In this paper, we go a step further and advocate 
including rapid prototyping as an integral part of the design 
process (cf., Figure lb). This will enable performing correct- 
ness verification, functionality and performance tests under 
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real operating conditions early enough in the design cycle that 
resulting feedback and insight can be effectively incorporated 
into the design. Rapid prototyping is complimentary to current 
testbeds and tools which are typically used to produce a beta 
version of the final implementation, a step just before public 
release. Therefore, testing a protocol under real conditions 
often happens at the end of the development cycle or even 
after it is over. 

We postulate that what is needed is a tool that makes 
prototyping as quick, easy, and effortless as possible. To this 
end, we introduce Prawn (PRototyping Architecture for Wire- 
less Networks), a novel software environment for prototyping 
high-level (i.e., network layer and above) wireless network 
protocols. Prawn's approach to rapid prototyping is based on 
two main components: 

• The Prawn Engine, a set of basic building blocks atop 
which protocols and services can be prototyped. These 
building blocks include functions such as neighbor dis- 
covery, link assessment, and device configuration. 

• The Prawn Library, an API that provides protocol de- 
signers with easy and transparent access to the underlying 
building blocks. Prawn deliberately provides a concise set 
of communication primitives, yet sufficient for a wide 
range of high-level wireless protocols. 

Prototypes implemented with Prawn are not expected to be 
optimized, offering edge performance. Rather, our focus with 
Prawn is on obtaining, quickly and with little effort, a complete 
and fully functional instantiation of the system. Prawn makes 
prototyping as simple as writing network simulation scripts, 
with the difference that testing is done under realistic condi- 



tions. 1 Assessing these conditions is done through the Prawn 
Engine, which runs as a background process that proactively 
performs tasks such as neighbor discovery and link quality 
assessment. This feature allows Prawn to provide accurate and 
up-to-date feedback from the wireless interface. 

As shown by the several case studies presented in this paper, 
Prawn prototypes can be used for functional assessment as 
well as both absolute and comparative performance evaluation. 
Once the prototype has been extensively tested and thoroughly 
validated, and its functional design tuned accordingly, it is then 
ready for final implementation (which is out of the scope of 
Prawn). 

In summary, Prawn's contributions are as follows. 

1) Prawn enables rapid prototyping which is key to testing 
and evaluating network protocols and services under real 
operating conditions as early as possible in the design 
cycle. 

2) Prawn provides an easy-to-use and extensible proto- 
typing interface which makes prototyping considerably 
simpler and faster requiring only basic programming 
skills. Prawn is to "live" experimentation what scripts 
are to simulations. Furthermore, new primitives can be 
easily incorporated as needed. 

3) Prawn includes a flexible active neighborhood discovery 
mechanism which provides configurable neighborhood 
probing and power control mechanisms. 

The remainder of this paper is organized as follows. We put 
our work on Prawn in perspective by reviewing related work in 
the next section. Section III provides an overview of Prawn, 
while in Sections IV and V we describe Prawn's two main 
components in detail. We evaluate the overhead introduced by 
Prawn in Section VI and present in Section VII a number 
of case studies showing how Prawn makes prototyping fast 
and simple. Finally, we present our concluding remarks and 
directions for future work in Section VIII. 

II. Related Work 

Simulations are perhaps the most widely used methodology 
for evaluating network protocols. They allow designers to 
evaluate the system at hand under a wide range of conditions 
(e.g., different mobility models, node heterogeneity, varying 
channel conditions). They also allow the exploration of the 
design space by enabling designers to vary individual protocol 
parameters (e.g., timers) and combinations thereof. Finally, 
they are instrumental for scalability analysis and they offer 
reproducibility. Examples of well known simulation platforms 
include NS-2 [8], OPNET [9], GloMoSim [10], and Qual- 
Net [11]. 

Emulation tries to subject the system under consideration to 
real inputs and/or outputs. Environments like EMPOWER [12] 
or Seawind [13] emulate the wireless medium by introduc- 
ing packet error rates and delays. Other emulators like m- 
ORBIT [14] also emulate node mobility by space switching 
over a testbed of fixed nodes. A key advantage of emulation in 
the context of wireless/mobile networks is to facilitate testing 

Currently, Prawn targets IEEE 802.11 networks, although its design can 
be extended to run atop other wireless network technologies. 



by avoiding, for example, geographic and mobility constraints 
required for deployment. 

More recently, a number of projects have pioneered the 
field of wireless protocol evaluation under real conditions. 2 
They include testbeds such as Orbit [1], Emulab [19], 
Roofnet [5], Mint-m [4], the work reported in UnWiReD [2] 
and Netbed [3], as well as tools that support protocol imple- 
mentation like the Click modular router [6] and XORP [7]). 
As previously pointed out, such tools and Prawn have different 
goals, address different phases of the design process, and are 
therefore complementary. While tools like Click and XORP 
targets the final implementation at the final stages of protocol 
design, Prawn focuses on prototyping a research proposal at 
the very early stages of the design process. Therefore, through 
Prawn, protocol designers can very quickly and easily generate 
a fully functional, but non-optimized, implementation for live 
testing in real scenarios. 

In the context of wireless sensor networks (WSNs), Polastre 
et ah [20] propose SP (Sensornet Protocol), a unifying link 
abstraction layer. SP runs on Tiny OS [21] and provides an 
interface to a wide range of data-link and physical layer 
technologies. Prawn and SP roughly share the same functional 
principles, e.g., data transmission, data reception, neighbor 
management with link quality, etc. However, they have quite 
different goals. First, SP only manages the neighbor table; 
it neither performs neighbor discovery nor provides link as- 
sessment. Second, SP is designed for WSNs whereas Prawn 
is for general IEEE 802.11 networks. Finally, while SP aims 
at optimizing the communication and unifying different link 
layers in WSNs, Prawn aims at facilitating and simplifying 
prototype implementation. 

EmStar [22] is another development environment for WSNs 
and runs on the Intel Stargate platform [23]. It is similar in 
essence to Prawn since it provides a set of primitives that upper 
layers can use. However, EmStar supports implementation by 
focusing on modularity and code reuse. Its architecture is quite 
complex and its use requires quite sophisticated development 
skills when compared to Prawn standards. 

MAPI [24] is an API especially developed for wireless 
networks based on the Wireless Tools [25]. It provides a set 
of simple primitives to obtain information from the underly- 
ing wireless device. Besides accessing information from the 
wireless device through a simple API, Prawn also runs an 
active daemon that performs neighborhood discovery with link 
quality assessment, as well as sending/receiving mechanism. 

III. Prawn Overview 

Prawn targets prototyping protocols and services at the 
network layer and above. Simplicity was a major goal we 
had in mind when designing Prawn; we wanted to ensure that 
learning how to use Prawn would be as intuitive and immediate 
as possible requiring only basic programming expertise. For 
example, in Prawn, sending a packet at a given transmit power 

2 Given the focus of this paper, we highlight related efforts that target 
wireless networks. However, similar tools for Internet research have been 
proposed; notable examples include VINI [15], PlanetLab [16], X-Bone [17], 
and Violin [18]. 



2 



Designer Space 



Prawn Library 



Prawn Engine 

T> — TTT> — 1\ 



.IP \ / 






Wireless Tools 


Loopback 


Wireless Driver 



TABLE I: Prawn's command line options. 



Option 


Parameter 


Default 


-N name 


node ID 


hostname 


-b period 


beacon period in ms 


10000 


-h 


help 


- 


-d 


daemon mode 


- 


-v 


verbose mode 


- 


-vv 


more verbose 


- 


-p port 


neighbor port 


3010 


-c port 


client port 


3020 


-i I 


uses wireless interface I 


athO 


-P 


set transmit power level 




-n 


no power control features 




-W window 


window size for PER 


5 


-V 


version 





Fig. 2: Prawn architecture 



level is performed by a single primitive and takes one line 
of code. Our focus was thus to provide: (1) a concise, yet 
complete set of functions to realize high-level protocols and 
(2) a simple, easy-to-use interface to provide access to Prawn's 
functionalities. 



A. Prawn Architecture 

Prawn consists of two main components: (i) the Prawn 
Library (cf., Section IV), which provides high-level primitives 
to send and receive messages, retrieve information from the 
network, etc; and (ii) the Prawn Engine (cf., Section V), which 
implements the primitives provided by the Prawn Library. 

The current implementation of Prawn runs on Linux atop 
IP for backward compatibility with the global Internet. The 
interaction between the Prawn Engine and the physical wire- 
less device relies on the Wireless Tools [25]. This set of 
tools allows retrieving information from most wireless devices 
as well as setting low-level parameters. Furthermore, it is 
available with most Linux distributions. 

Prawn's components, how they interact with one another 
and with the underlying operating system are illustrated in 
Figure 2. As highlighted in the figure, Prawn's functionali- 
ties are accessible through the Prawn Library. Messages and 
requests received from the library are then processed by the 
Prawn Engine. The Prawn Library and Engine communicate 
with each other through the loop-back interface using a simple 
request/reply mechanism. This choice simplifies modularity 
and portability. 



B. How to Use Prawn 

Running Prawn requires only a few basic steps. First, it 
needs to be configured and installed on the machines that 
will be used in the experiments. In particular, in the Prawn 
configuration file it is necessary to set the names of the 
wireless interface and network (e.g., the ESSID). Optionally an 
IP address can be specified. Otherwise, Prawn will randomly 
generate an IP address in a default subnetwork. 



Using Prawn itself only requires two operations (as de- 
scribed below), namely executing the Prawn Engine and 
including the Prawn Library in the prototype code. 

1: Starting the Prawn Engine. Prawn is distributed under 
GPL license and available online [26]. Once compiled, the 
Prawn Engine is launched as a command line program on 
machines connected in "ad hoc" mode. Prawn is supposed to 
run in daemon mode, but can run in console mode for de- 
bugging purposes. As stated before, Prawn provides a number 
of options that can be set/configured at the execution of the 
Engine. They are listed in Table I. Other options (e.g., the 
number of lost beacons required to consider that a node is no 
more a neighbor) are tunable in the prawn, cf g configuration 
file. 

2: Using the Prawn Library. The Prawn Library (described 
in detail in Section IV) is composed of a set of primitives 
that are linked to the prototype through standard include files. 
Currently, prototypes can be developed either in C or in Perl 
(a Java version is about to be released). For C development, 
the file prawn.h should be included in the header of the 
prototype code. Similarly, the file prawn.pl is to be included 
for prototypes developed in Perl. 



C. "Hello World!" 

To illustrate the use of Prawn, we describe how to imple- 
ment a simple "hello world" prototype using Prawn's Perl 
library. In this example we send a message from Bob to Alice. 

Step 1. Launch Prawn with "prawn -d -N Bob" in the 
first machine and "prawn -d -N Alice" in the second 
machine. 

Step 2. Get the first machine ready to receive messages by 
executing the following Perl script: 



require "prawn.pl"; 
while( !@Message) { 
@Message=Prawn_Receive() ; 

} 

print 'Received : ' .$ Message [4]/ from ' .$ Message [2]." \n" ; 



Step 3. On the other machine launch the following Perl script: 
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require "prawn.pl"; 
Prawn_Send(" Hello World! 



The result is trivial: Alice sends a "Hello World" mes- 
sage to Bob, and Bob prints "Received: Hello World 
from Alice" on the screen. However, this simple example 
aims at showing the level of abstraction provided by Prawn, 
where low-level system knowledge (e.g., sockets, addressing) 
is required. More elaborated examples will be presented in 
Section VII. 

IV. The Prawn Library 

The Prawn Library, currently implemented in C and Perl, 
provides a set of high-level communication-oriented functions. 
They hide from protocol designers lower-level features such 
as addressing, communication set-up, etc. Their syntax is 
quite simple and intuitive. Prawn's current set of primitives 
addresses basic functions required when prototyping a high- 
level communication protocol; nevertheless, Prawn was de- 
signed to be easily extensible allowing new primitives to be 
implemented and integrated. The primitives currently available 
are: 

• Prawn_Inf o(): Returns information on the configuration 
of the local Prawn Engine. Basically, it consists of the 
list of settings chosen when launching the daemon (cf., 
Table I). Some examples are the node's ID, interface port 
number, and beacon period. 

• Prawn_Neighbors(): Returns the list of the node's one- 
hop and two-hop neighbors as well as statistics concern- 
ing the quality of the respective links. In Section V, a 
thorough explanation of the information returned by the 
Engine will be given. 

• Prawn_Send(Message, ID, TX_Pwr): Sends Message to 
node ID; the optional argument TX_Pwr can be used to 
explicitly set the transmit power to be used during the 
transmission. Message can be a string, a number, a data 
structure, or any other data or control message, depending 
on the prototyped protocol (e.g., a route request primitive 
of a route discovery protocol). 

• Prawn_Send_Broadcast(Message, TX_Pwr): Sends a 
broadcast message containing Message; in a similar way 
to Prawn_Send(), the optional argument TX_Pwr allows 
to set the transmit power. 

• Prawn_Receive(): Checks if a message has been re- 
ceived; if so, the message is returned. This primitive is 
non-blocking: if no message has been received, it just 
returns zero. 

V. The Prawn Engine 

The Prawn Engine is event-driven, i.e., its main process 
remains asleep waiting for an event to occur. An event can 
be triggered by a request from the Prawn Library (coming 
through the loop-back interface) or by a message received 
on the wireless interface. The main loop of the Engine is 
described in pseudo-code in Algorithm 1. The main events 
are: 



Algorithm 1 The Prawn Engine's main loop. 

1: Timeouts time.tojnext .regular .event 

2: while 1 do 

3: if (Timeout) then 

4: Perform regular operation 

5: Timeouts time .to jnext -regular .event 

6: else if (Client Request) then 

7: Perform requested action 

8: else if (Neighbor Message) then 

9: if (Message == Data) then 
10: Send packet to the client process 

11: else if (Message == Control) then 
12: Update neighborhood list and statistics 

13: end if 
14: end if 

15: end while 



Control Event: Prawn performs some tasks on a regular basis 
controlled by a timer. For instance, a timeout event triggers 
the transmission of neighborhood discovery control messages 
(beacons or beacon replies, cf. Sections V-B and V-C). 

Client Request: This is an asynchronous event. It is triggered 
by a library call, requesting an action from the engine (e.g., 
sending a packet or retrieving the current neighbor list). 

Neighbor Message: This event is also asynchronous. It is trig- 
gered when messages from neighbors are received through the 
wireless interface. These can be either control messages to be 
processed by the engine or user messages to be delivered to the 
prototype through the library's primitive Prawn_Receive(). 



A. Packet Format 

All packets transmitted by Prawn start with a one-byte Type 
field that defines the structure of the rest of the packet. In its 
current version, Prawn defines four types of packets as shown 
in Table II. 



TABL E II: Prawn's packet 



Type # 


Function 





Reserved 


1 


Beacon 


2 


Data 


3 


Feedback 



types. 



B. Beaconing 

To build and maintain the list of neighbors, each node 
running Prawn broadcasts 24-byte beacons periodically. The 
beacon period is configurable depending on the requirements 
of the prototype under development. By default, the Prawn 
Engine is configured to test connectivity under different power 
levels (useful for instance to prototype topology control al- 
gorithms based on power control [27], [28]). The Prawn 
Engine applies a round-robin policy to continuously change 
the transmit power. A beacon is first broadcast with the 
lowest power value. The transmit power level is successively 
increased for each beacon, up to the maximum transmit power. 
We call this sequence of beacons a cycle. The different values 
of the transmit power are either obtained from the interface 



4 



15 16 



31 



Transmitter ID 



I Type | Power | 
I 

+ 
I 

+ 
I 

+- 

I 

+ 
I 

+- 



I 

+ 
I 

+ 
I 

I Beacon Period | 



15 16 
Type | Unused | 



31 



MAC Address 

+ + _ 



I Sequence Number | 



Fig. 3: Prawn beaconpacket format. 



or set by the user. This cycle is then repeated at every beacon 
period. This way, the time elapsed between two beacons sent 
with the same transmit power is equal to the beacon period. 

Of course, the power control feature is optional, depending 
on the designer's needs. If this feature is disabled, each cycle is 
then composed of only one beacon, sent at the default transmit 
power level. The number of transmission power levels and 
their values are customizable, depending on the power control 
features provided by the wireless interface under utilization. 

The beaconing packet format, which is illustrated in Fig- 
ure 3, includes the following fields: 

. Type: This field is set to '1' (cf., Table II). 

• Transmit Power: Transmit power used to send the bea- 
con. 

• Transmitter ID: Sender identifier. 

• Beacon Period: Time period between two beacons 
transmitted with the same power level (set by the user). 

• MAC Address: MAC address of the transmitter. 

• Sequence Number: Sequence number of the beacon. 

Upon the reception of a beacon (or sequence of beacons if 
different transmit powers are used), various statistics can be 
derived. For instance, a node A can determine, at a given point 
in time, the minimum transmit power that B should use to send 
messages to A. This value corresponds to the lowest transmit 
power among all the beacons received by A from B. Of course, 
the minimum transmit power may change over time, and will 
be updated along the successive cycles. 

Configuring Prawn is important to achieve an adequate 
balance between performance and overhead. For example, 
sending beacons too frequently would generate high overhead. 
On the other hand, limiting the number of beacons is likely to 
result in out-of-date measures. For these reasons, the beacon- 
ing period is one of Prawn's customizable parameters and its 
value is carried in the header of each beacon sent. A beacon 
is considered lost when the beaconing period (included in 
previous received beacons) times out. By default, a neighbor is 
removed from a node's neighbor table when three consecutive 
beacons from this neighbor have been lost (or when three 
consecutive beacons for every transmit power have been lost). 
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Fig. 4: Prawn feedback packet format. 



C. Replying to Beacons 

Nodes reply to beacons using 16-byte feedback pack- 
ets, as shown in Figure 4. Feedback packets summarize 
neighborhood- and link quality information as perceived by 
the receiver of the beacons. This feature allows verifying the 
bidirectionality of links. Feedback packets are sent to every 
neighbor after a complete cycle. 3 Prawn keeps sending feed- 
back packets also in the case where a neighbor is considered 
lost (a unidirectional link may still exist between the two 
nodes). Feedback packets contain the following fields: 

• Type: This field is set to '3' (cf., Table II). 

• Destination ID: Identifier of the neighbor concerned 
by the feedback. 

• Minimum Received Transmit Power: Is the transmit 
power of the beacon received with the weakest signal 
strength from that particular neighbor. 

• Maximum Received Power Strength (in dBm): Is the 
maximum signal strength measured when receiving bea- 
cons from that particular neighbor. 

The rationale for reporting the transmit power of the weakest 
beacon received from a particular neighbor is that it allows 
to roughly characterize the quality of the corresponding link. 
This estimation is also confirmed using the maximum received 
signal strength measured within a cycle. 

Although destined to a single neighbor, feedback packets are 
broadcast and thus overheard by all one-hop neighbors. This 
way, nodes can obtain information on two-hop neighborhood 
(cf., Figure 5). 

D. Getting Information from Prawn 

When a node calls the Prawn_Neighbors() primitive, the 
engine returns a data structure with information about the 
node's neighborhood. This information can be also obtained by 
running Prawn in console mode, e.g., for debugging purposes. 
Figure 5 shows a snapshot of the information returned by 
the Prawn Engine running in console mode on a node named 
"Bob". This snapshot shows a list of Bob's neighbors, along 
with statistics on last beacons received by each neighbor for 
every transmit power. Basically, Bob has two active neighbors, 
John and Alice. The link between Bob and Alice has, on 
average, better quality than the one between Bob and John; 
indeed for beacons sent at 1 mW and 12 mW, only 4/5 of 
them have been received. 

3 Note that if the power control feature is disabled, then the cycle is unitary. 
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Neighbor 1 
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60mW 



Act: 

Act: 

Active 

Active 
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R 

R 

R 

R 

R 



[0.015848932 nW (-78 dBm) ] 

[0.079432823 nW (-71 dBm)] 

[0.199526231 nW (-67 dBm)] 

[0.501187234 nW (-63 dBm)] 

[1.995262315 nW (-57 dBm)] 



^Neighbor 1 
J0HN Detailed 
; Information 

4/5 
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Statistics 
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^ 2-hop 
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Active 00:40:96:A9:30:A7 
Weakest beacon received by thi 



Beacon period : 10000 
1 neighbor : 1 mW 



I Neighbor 2 
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lmW 
12mW 
21mW 
29mW 
60mW 



Active 
Active 
Active 
Active 
Active 



R 

R 

R 

R 

R 



9 [0.158489319 nW (-68 dBm)] 

10 [0.794328235 nW (-61 dBm)] 

10 [1.995262315 nW (-57 dBm)] 

10 [3.981071706 nW (-54 dBm)] 

10 [12.58925412 nW (-49 dBm)] 



5/5 
5/5 

5/5 B 



■49 dBm) JOHN (1 mW, -56 c 



J Beacons' 
Statistics 

^ 2-hop 
==== — ^ Neighbors 



Fig. 5: Information provided by Prawn for a node whose ID 
is "BOB". 
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I Type | Pwr | Payload Size | 
I Payload | 
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Fig. 6: Prawn data packet. 



TABLE III: Average delays measured using Prawn on a Dell 
Latitude XI laptop. 





100-byte packets 


1,400-byte packets 


Delay to send 


0.13 ms, a=0.016 ms 


0.15 ms, a=0.018 ms 


Delay to receive 


0.14 ms, (7=0.008 ms 


0.15 ms, a=0.008 ms 



As previously described, neighborhood information is ob- 
tained through beacons and feedback packets. More specifi- 
cally, broadcast beacons are used to build the list of direct 
neighbors. This list is established by gathering the transmitter 
ID of each received beacon. Moreover, data included in 
beacons and feedback packets inform each node what is the 
minimum transmit power required to reach a neighbor. Such 
information is of primary importance in assessing link quality. 
Another prominent link characteristic is the error rate, which 
is determined according to the beacon period included in each 
beacon transmitted. The Engine considers a beacon as lost 
when it is not received within the beacon period indicated by 
the corresponding neighbor. The size of the receiving window 
used to compute the error rate is customizable. For instance, 
in Figure 5, the error rate for John's packets transmitted at 
12 mW is 1/5, because over the 5 most recent 12 mW beacons 
transmitted by John, only 4 have been received. 

When receiving a beacon, the Prawn Engine retrieves and 
saves the received signal strength. Along with the transmit 
power of the beacon (which is also included in the beacon), 
the received signal strength returned by the engine helps to 
evaluate the signal attenuation. The difference between the 
transmitted power level indicated in the beacon and the signal 
strength measured when the beacon is received can also be 
used by a protocol to characterize link quality. 

E. Sending and Receiving Messages 

Two other key functions performed by the Prawn En- 
gine are transmission and reception of data (triggered by 
the Prawn_Send() and Prawn_Receive() primitives, respec- 
tively). The engine is in charge of the communication set up, 
namely opening sockets, converting the receiver identifier to 
a valid IP address, encapsulating/decapsulating packets, and 
adjusting the transmit power before transmission. Figure 6 
shows the structure of the data packets, which contain the 
following fields. 

• Type: This field is set to '2' (cf., Table II). 

• Transmit Power: Power used to send the packet. 

• Payload Size: Size of the payload field. 

• Payload: Data being sent. 



TABLE IV: Average delays measured using Prawn on a HP 
Compaq nx7000 laptop. 





100-byte packets 


1,400-byte packets 


Delay to send 


0.23 ms, a=0.046 ms 


0.23 ms, (7=0.021 ms 


Delay to receive 


0.13 ms, (7=0.007 ms 


0.14 ms, (7=0.007 ms 


TABLE V: Average delays measured using Prawn on a mini- 
PC. 




100-byte packets 


1,400-byte packets 


Delay to send 


1.09 ms, a=0.038 ms 


1.15 ms, a=0.043 ms 


Delay to receive 


0.32 ms, (7=0.015 ms 


0.38 ms, (7=0.022 ms 


TABLE VI: Average delays measured using Prawn on a Nokia 
N770. 




100-byte packets 


1,400-byte packets 


Delay to send 


3.09 ms, a=0.21 ms 


4.22 ms, a=0.22 ms 


Delay to receive 


1.47 ms a=0.22 ms 


1.61 ms, cr=0.27 ms 



Data packets are sent using UDP to the corresponding IP 
address. This explains why their header does not need to 
include the destination ID. 4 On the receiver side, the engine 
listens on an open socket for any incoming packets. Packets 
are then decapsulated and sent to the prototype which retrieves 
them by using the Prawn_Receive() primitive. 

VI. Performance of Prawn 

In this section, we present our measurements of the over- 
head introduced by Prawn (in terms of delay and throughput) 
on the different platforms that compose our testbed. We show 
that Prawn delivers adequate performance even in the case of 
platforms with limited computation- and memory capability. 

A. Setup 

The experiments reported here were performed using dif- 
ferent platforms from our testbed, namely: 

4 Note that the same method cannot be used for beacons, since beacons are 
always sent broadcast at IP level and thus contain the broadcast address. 
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• Laptop 1. Dell Latitude XI featuring and Intel Pen- 
tium M 733 Processor at 1.1 GHz, 1.2 GB of memory 
and an embedded Intel PROAVireless 2200BG 802.11b/g 
chipset. The Operating System (OS) is Linux Fedora Core 
6, 2.6.18.2 kernel, with the ipw2200 driver. 

• Laptop 2. HP Compaq nx7000 featuring an Intel Pen- 
tium M Processor at 1.4 GHz, 512 MB of memory and 
a Netgear WG511T 802.11b/g wireless Cardbus adapter. 
The operating system is Linux Fedora Core 6, 2.6.18.2 
kernel, with the madwifi-ng driver for Atheros chipsets. 

• Mini-Pc. VIA Eden EBGA fanless processor at 
600 MHz, with 512 MB of memory and a Cisco Aironet 
802.1 la/b/g wireless PCI adapter (PI21AG-E-K9). The 
OS is Linux Fedora Core 5, 2.6.16.16 kernel, with the 
madwifi-ng driver for Atheros chipsets. 

• PDA. Nokia N770 Internet Tablet, powered by a 
250 MHz ARM based Texas Instruments 1710 OMAP 
processor, 64 MB of memory and an embedded 802.1 lb/g 
chipset. The OS used is the Nokia Internet Tablet 0S2006 
Edition. 

Our experiments were performed in a research laboratory 
(i.e., indoors, under radio interference of existing wireless 
networks, etc.). Measurements were obtained between two 
nodes forming a one-hop topology. 

B. Average Delay 

When sending a message, a prototype using Prawn calls the 
Prawn_Send() primitive. This function forwards the packet to 
the engine, which triggers an event. If not idle, the engine 
terminates its current tasks (e.g., sending/receiving a beacon, 
receiving a packet) and encapsulates the message. Then it 
changes the transmit power (if requested) and sends the packet 
to the corresponding neighbor through the wireless interface. 
Our goal here is to measure the additional delay incurred by 
Prawn (without Prawn, a message would be sent directly to the 
wireless interface) and show that it is small enough compared 
to the overall message delivery delay. 

To measure the additional delay incurred by Prawn, we 
implemented a simple application program that calls the 
Prawn_Send() primitive and records a timestamp. Then the 
Prawn Engine receives the packet from the loop-back interface, 
encapsulates it, changes the transmit power if requested, and 
generates a second timestamp just before the packet is finally 
sent through the wireless interface. Experiments have been 
performed for two different packet sizes, namely 100- and 
1,400 bytes. 

Tables III and IV show the results when running Prawn 
on our testbed laptops. Reported averages were obtained 
over 10,000 measures. These results are quite encouraging as 
additional delays of up to 0.20 ms for sending a message are 
quite reasonable for the purposes of a prototype. 

Measured delays for the the mini-PC and the Nokia N770 
are presented in Tables V and VI. As expected, the delays are 
higher, but still sufficiently non-intrusive when observing the 
behavior of routing protocols or addressing mechanisms with 
real wireless links and users. 



TABLE VII: Average throughput using Prawn on a Dell 
Lat itude XI laptop. 





100-byte packets 


1,400-byte packets 


With Prawn 


3.0 Mbit/s 


17.9 Mbits/s 


Without Prawn 


3.1 Mbit/s 


18 Mbit/s 



TABLE VIII: Average throughput using Prawn on a HP 
Co mpaq nx7000 laptop. 





100-byte packets 


1,400-byte packets 


With Prawn 


4.7 Mbit/s 


25.6 Mbits/s 


Without Prawn 


4.9 Mbit/s 


25.9 Mbit/s 


TABLE IX: Average throughput of mini-PC. 




100-byte packets 


1,400-byte packets 


With Prawn 


2.2 Mbit/s 


11.6 Mbits/s 


Without Prawn 


5.4 Mbit/s 


22.2 Mbit/s 


TABLE X: Average throughput of Nokia N770. 




100-byte packets 


1,400-byte packets 


With Prawn 


0.3 Mbit/s 


2.3 Mbits/s 


Without Prawn 


0.8 Mbit/s 


4.9 Mbit/s 



C. Throughput 

We also measured the maximum throughput supported by 
Prawn. To this end, we compared the throughput of two Perl 
scripts communicating by sending data directly through the 
wireless interface (i.e., without Prawn), against having them 
send data using Prawn's send/receive primitives. Results for 
the laptop nodes are presented in Tables VII and VIII. 5 

These results are again very encouraging: the throughput 
achieved with Prawn is comparable to what was obtained 
without Prawn, which shows that the overhead introduced by 
Prawn is mostly negligible. However, as shown in Tables IX 
and X, this is not the case for the less capable platforms, 
namely the mini-PC and Nokia N770 which exhibit already 
very low throughput without Prawn. The per-packet process- 
ing performed by Prawn increases the bottleneck, limiting 
throughput further. 

Nevertheless, we argue that when testing protocol func- 
tionality and correctness, achieving high throughput is not 
critical. Indeed, most target protocols such as routing, topology 
control, localization, addressing/naming schemes, etc. generate 
typically short control messages relatively sparse in time. 

D. Communication Overhead 

The communication overhead incurred by Prawn is due to 
its beacons, feedback messages, as well as additional message 
headers. This overhead can be easily estimated as shown in the 
following example. Let us consider a Prawn prototype running 
on a 6-node wireless network where nodes are all in range of 
one another. The beacon period is set to the default value 
of 5, 000 ms, and 5 different transmit power levels are used 

5 Recall that IEEE 802.1 la/g (we used 802. llg in our experiments) has a 
maximum nominal transmission rate of 54 Mbps. Actually, this is the rate for 
the payload of 802.11 frames; headers, trailers, and handshake packets are sent 
at lower rates, which makes the effective throughput drop below 40 Mbps. 
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Fig. 7: Neighborhood monitoring experiment setup. 



for the beacons. Thus, during a beacon period each node: (1) 
broadcasts 5 beacons (one for each transmit power) and (2) 
broadcasts 5 beacon replies (one for each neighbor). We also 
have to account for an additional 4 (header) bytes per packet. 

For the case that the prototyped protocol sends 10 data 
packets per second, during a beacon period, a node sends a 
total of 5 beacons, 5 beacon replies, and 50 data packets. The 
corresponding overhead is 120 bytes for the beacons, 80 bytes 
for the beacon replies, and 200 bytes for data packet headers. 
We obtain 400 bytes of overhead per beacon period, or 640 
bits/s. Since we have 6 nodes in the network, the overhead for 
the whole network is 3.84 Kbit/s. 

The important point here is that, as long as protocol design- 
ers understand the cost incurred by Prawn, they can, besides 
testing their prototype under real conditions, also conduct 
absolute/relative overhead analysis. 

VII. Prototyping with Prawn 

Prawn is intended to be a tool for prototyping a wide 
range of communication algorithms for heterogeneous wireless 
networks. In this section, we first illustrate the use of Prawn 
through a number of case studies, highlighting its range of 
applicability and ease of use as well as how it can be employed 
to evaluate and test protocols. 

A. Case Study 1: Neighborhood Monitoring 

In this case study we use Prawn to implement a simple 
neighborhood monitoring protocol. The purpose of this ex- 
ample is to show how Prawn simplifies neighbor discovery 
and link quality assessment. The experimentation setup was as 
follows: four heterogeneous nodes running Prawn were placed 
at different locations in our lab as depicted in Figure 7. This 
figure also lists the types of nodes (for further details, see 
Section VI). 

We used a fifth node running Prawn executing a simple 
script registering the received signal strength from each static 
node. This fifth node was a laptop that we moved along the 
corridor at walking speed. Figure 8a plots the received signal 



================ Neighbor List for node Laptop-1 ================ 

89C2 Active : 14 : A7 : FA : 8 9 : C2 Beacon period : 1000 PDA 

Weakest beacon received by this neighbor : 100 raw 

lOOmW Active 01020 R S 5 B 5 [3.9810717 nW (-54 dBm) ] 5/5 

2hop-Neighbors : MiniPC-2 (100 raw, - 78 dBm) 
MiniPC-1 (100 raw, - 61 dBm) 



3051 Active 00 : 40 : 96 : A7 : 30 : 51 Beacon period : 1000 MiniPC-1 
Weakest beacon received by this neighbor : 100 mW 

lOOmW Active 01020 R S 9 B 9 [0.0158489 nW (-78 dBm)] 4/5 

2hop-Neighbors : PDA (100 mW, -50 dBm) MiniPC-2 (100 mW, -56 dBm) 

Fig. 9: Snapshot of Prawn running in console mode on the 
mobile laptop at the beginning of the experiment. 

================ Neighbor List for node Laptop-1 ================ 

89C2 Dead : 14 : A7 : FA : 8 9 : C2 Beacon period : 1000 PDA 

Weakest beacon received by this neighbor : 100 mW 

lOOmW Dead 01082 R S 73 B 70 [0.0158489 nW (-78 dBm)] 0/5 

2hop-Neighbors : MiniPC-2 (100 mW, - 75 dBm) 
MiniPC-1 (100 mW, - 58 dBm) 



3051 Active 00 : 40 : 96 : A7 : 30 : 51 Beacon period : 1000 MiniPC-1 
Weakest beacon received by this neighbor : 100 mW 

lOOmW Active 01119 R S 109 B 119 [0.0794 nW (-71 dBm)] 4/5 

2hop-Neighbors : PDA (100 mW, -50 dBm) MiniPC-2 (100 mW, -55 dBm) 



2F6D Active 00:40: 96:A9:2F: 6D Beacon period : 1000 MiniPC-2 
Weakest beacon received by this neighbor : 100 mW 

lOOmW Active 01119 R 1 S 134 B 139 [0.0794 nW (-71 dBm)] 3/5 

2hop-Neighbors : PDA (lost) MiniPC-1 (100 mW, -51 dBm) 
Laptop-2 (100 mW, -55 dBm) 



3051 Active 00 : 40 : 96 : A7 : 30 : 51 Beacon period : 1000 Laptop-2 
Weakest beacon received by this neighbor : 100 mW 

lOOmW Active 01120 R S 197 B 86 [199.526 nW (-37 dBm)] 5/5 

2hop-Neighbors : PDA (lost) MiniPC-2 (100 mW, -54 dBm) 
MiniPC-1 (100 mW, -75 dBm) 

Fig. 10: Snapshot of Prawn running in console mode on the 
mobile laptop at the end of the experiment. 



strength data collected by the moving node. It is interesting 
to remark how at the beginning of the experiment the laptop 
has only two direct neighbors: the PDA and the MiniPC-1. 
Indeed the curves for the other two nodes appear only after 20 
seconds. The same information can be deduced from Figure 9, 
which depicts a snapshot of the feedback received by Prawn in 
console mode. The same figure shows that the other two nodes 
(MiniPC-2 and Laptop-2) are in the two-hop neighborhood of 
the moving laptop. It can be also observed that at the end of the 
experiment the laptop has only three direct neighbors; indeed 
the PDA becomes too far and its curve in Figure 8a ends after 
around 75 seconds. This is also confirmed in Figure 10, which 
lists all the fixed nodes but has the PDA marked as dead. 6 

We compared the received signal strength results obtained 
with the Prawn prototype against what is reported by simula- 
tions of the same setup using NS-2 [8]. The discrepancy be- 
tween the two sets of results clearly illustrates the importance 
of testing wireless protocols under real conditions. Prawn's 

6 The reader is referred back to Section V for more details on how Prawn 
assumes that a node is no longer available. 
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(a) Received signal strength measured from the mobile laptop while (b) NS-2 simulation of the received signal strength from the mobile 
moving. laptop. 

Fig. 8: Received signal strength for the experiment with a mobile node and four static nodes. 



value-added is that it makes prototyping protocols as simple 
and fast as implementing them on a network simulator. 

B. Case Study 2: Node Localization in Wireless Mesh Net- 
works 

The previous case study can be extended for Wireless Mesh 
Networks (WMNs). In WMNs, mobile users connect to fixed 
wireless nodes (Wireless Mesh Routers - WMRs) belonging 
to the infrastructure. As illustrated in Figure 11, consider the 
case where WMR1, WMR2, and mobile node M are all neighbors 
(i.e., they are in range of one another). Then node WMR1, 
can approximately determine the direction of movement of 
M by measuring the received signal strength or the minimum 
transmit power of beacons received. In this particular example, 
suppose that WMR1 is experimenting decreasing link quality 
with M. WMR1 can use the feedback packets broadcast by an- 
other fixed node, say WMR2, to M. By examining these packets, 
WMR1 realizes that the link quality of WMR2 — M is not getting 
worse. Thus, WMR1 concludes M is moving approximately in the 
direction of WMR2. With this information, a routing process can 
choose to start forwarding packets to WMR2 in order to reach 
M. Note that this would also be very useful in the context of 
episodically-connected networks. Figure 12 shows a simple 
script that uses information from the Prawn Engine to find all 
neighbors of M sorting them by RSSI. 

Furthermore, by using the maximum received signal 
strength (already included in the feedback packets), a node 
can estimate its neighborhood's "virtual topology", where 
distances between nodes are based on signal strength (i.e., are 
given in mW or dBm). Note that these "virtual distances" be- 
tween nodes are not always proportional to euclidian distances, 
e.g., if the nodes are not in line-of-sight. Nevertheless, signal 
strength provides indeed a better characterization of link qual- 
ity than the physical distance between nodes. By using simple 
trilateration (with 3 or more neighbors), nodes can compute 
their locations more accurately. For the example illustrated 
in Figure 11, node WMR1 can compute the location of M by 
trilateration, using its own RSSI (Received Signal Strength 
Indication) on the link M - WMR1, along with the RSSIs on 
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Fig. 1 1 : Keeping track of moving nodes 



foreach $i (@Selected_Neighbors){ 

for (my $j=1; $j<=$Neighbor[$i->[0]]{Neighbors}[0]; $j++){ 
if ($Neighbor[$i->[0]]{Neighbors}[$j]{NAME} eq "M"){ 
push(@list_M, 

[$Neighbor[$i -> [0]] {NAME} , 
$Neighbor[$i] {Neighbors } [$j] {RSSI}]) ; 

} 

} 

} 



Fig. 12: Prototype of a simple node localization algorithm. 



the links M - WMR4 and M - WMR2 (broadcast respectively by 
neighbor nodes WMR4 and WMR2). 

This particular example illustrates the use of Prawn's fea- 
tures related to power control and signal measurements. It also 
show cases the modularity properties of Prawn's prototypes, 
which enables code reused. In other words, Prawn code to 
implement basic functions like neighborhood discovery can 
be reused by other (more complex) prototypes. 



C Case Study 3: Prototyping Other Protocols 

1) Flooding: Flooding is the simplest possible routing 
algorithm. Its basic operation is as follows: upon receiving 
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require "prawn.pl"; 
while(1){ 

while( !@Message) { 

$Message = Prawn_Receive(); 

} 

$msglD = unpack("N",$ Message [4]); 
if (!grep(/$msglD/,@ID_list)){ 

push(@ID_list,$msg I D) ; 

Prawn_Send_Broadcast($Message[4]); 

} 

@Message = (); 

} 



Fig. 13: Perl code of a flooding prototype 



a packet, each node sends it once to all its neighbors. Thus 
the only requirement to implement this algorithm is to be able 
to receive and broadcast packets. 

Prawn makes this algorithm easier to implement even 
for inexperienced programmers as they are abstracted away 
from lower-level functions like sockets, ports, addressing, 
etc. Flooding can be implemented simply by using the 
Prawn_Receive() and Prawn_Send_Broadcast() functions. 

Figure 13 shows how short and simple the flooding pro- 
totype using the Prawn Library is. This 12-line piece of 
code has been running successfully on our testbed and we 
have conducted intensive experimentation that has enabled us 
to understand the behavior of the flooding algorithm under 
realistic conditions and with real users. This behavior is not 
obvious and known a priori from simulations; for example, 
Cavin et al. tried to simulate the flooding [29] algorithm 
using three different simulators namely, NS-2, OPNET, and 
GloMoSim, with exactly the same parameters and scenarios. 
Surprisingly, the results were considerably different, depend- 
ing on the simulator used. 

2) Network Coding: While the previous section illustrates 
the use of Prawn to prototype one of the simplest protocols, we 
show, in this section, that Prawn can also be used to prototype 
more complex protocols. In particular, we show case the use 
of Prawn to prototype network coding algorithms [30], [31]. 
For example, COPE, whose principles and implementation are 
described in [31], is clearly rather complex. Our goal here is 
to show that some evaluation of network coding proposals 
could be easily done without requiring a fully-functional 
implementation of the algorithm. 

For clarity, we briefly explain the essence of network coding 
through a very simple example. In traditional forwarding, 
when a node A and a node B want to exchange data via a third 
node C, both send their packets to C, and then C forwards the 
packets to A and to B. Exchanging a pair of packets requires 
4 transmissions. Using network coding, instead of sending 
separate packets to A and B, node C combines (e.g., using 
the XOR function) both packets received from A and B, and 
broadcasts the encoded packet. Since A knows the packet it 
has sent, it can decode the packet sent by B (e.g. applying 
again the XOR function) from the encoded packet received 
from C. Similarly, B can decode the packet sent by A from the 

7 Of course, more elaborated variations of flooding exist, but here we 
consider it in its simplest form. 



require "prawn.pl"; 
my @Stdby=(); 
my @Msg=(); 

while(!@Stdby) {@Stdby = Prawn_Receive();} 
while(1){ 

@Msg = Prawn_Receive(); 

if (@Msg){ 

if ($Msg[2] ne $Stdby[2]){ 
$xored= " " ; 

for ($i=0;$i<=1400;$i++){ 

substr($xored ,$i , 1 , substr($Msg [4] ,$i , 1 ) " substr($Stdby [4] ,$i , 1 )) ; 

} 

Prawn_Send_Broadcast($xored) ; 
@Stdby=(); 

while(!@Stdby) {@Stdby = Prawn_Receive();} 

} 

else{ 

if ($Stdby[2] eq "NodeA") {Prawn_Send($Stdby[4], "NodeB");} 

else {Prawn_Send($Stdby [4] , " NodeA " ) ; } 

@Stdby=@Msg; 

} 

@Msg=(); 
} 

} 



Fig. 14: Perl code of a network coding algorithm 



same packet received from C. Thus, with this method, only 3 
transmissions, instead of 4, are required. 

Using Prawn, we implemented a prototype of the algorithm 
described above. As shown in the Perl code running on node 
C (Figure 14), the first received packet is stored in a standby 
variable ($Stdby), then the next packet is stored as $Msg. If 
the two stored packets are not received from the same node, 
then they are XORed and broadcast. If, instead, both packets 
are from the same node, it does not make sense to XOR them. 
In this case, the packet stored in standby is sent as a normal 
unicast packet, and the latest packet goes to the standby queue. 

We also implemented a prototype of a traditional forwarding 
algorithm. We compare both implementations to measure the 
performance gains achieved by network coding when A sends 
10,000 packets of 1,400 bytes to B and vice-versa. Without 
network coding, the total amount of data transmitted was 
54 MB on both links. With network coding, only 44 MB 
were sent. With this code as a starting point, network coding 
protocol designers can test and tune their algorithms on real 
platforms under real conditions. 

3) Topology Control: Topology control algorithms require 
updated information about neighbors. Selecting good neigh- 
bors is often beneficial for the whole network. Prawn sup- 
ports varied neighbors selection criteria relying on cross- 
layer information. For instance, in order to save energy and 
reduce interference, neighbors with lowest required transmit 
power can be selected. Conversely, neighbors with the highest 
signal strength received could be chosen. Many recent research 
efforts relying on cross-layer approaches would benefit from 
Prawn's lower layer information. 

The code in Figure 15 shows how to get in 7 lines a list 
of neighbors sorted according to their receive signal strength. 
This code is running successfully on our testbed consisting 
of heterogeneous nodes. An important point here is that the 
received signal strength value retrieved from the wireless 
driver can be different depending on the wireless device model. 
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require "prawn.pl"; 
$Neighbor = Prawn_Neighbors(); 
for ($i=1; $i<=$Neighbor[0]; $i++){ 

push(@rx_power_list, [$i,$Neighbor[$i]{MAX_POW}]); 

} 

@sorted_list = sort {($b)->[1]<=>($a)->[1]} @rx_power_list; 
@Selected_Neighbors=@sorted_list[0. .1 ]; 



Fig. 15: Perl code of a topology control prototype 



If the neighbors do not have all the same wireless cards, the 
selection could be biased. This is an example of practical 
issue that cannot be taken into account from simulations. 
Using Prawn, designers can evaluate their proposal taking into 
account the features and performance of off-the-shelf hardware 
and drivers. 

VIII. Conclusion 

In this paper we proposed Prawn, a novel prototyping tool 
for high-level network protocols and applications. Prawn's 
main goal is to facilitate the prototyping of wireless protocols 
so that prototyping becomes an integral part of the design 
process of wireless systems. 

Prawn is not an alternative to simulation or any other evalu- 
ation method. Instead, it stands as a complementary approach 
that goes beyond simulation by taking into account real- world 
properties. Prawn surfs the wave of recent research efforts 
toward making implementation easier (e.g., Click and XORP), 
but as a preliminary phase in this process. The designer has 
to keep in mind, however, that the performance of a prototype 
does not always match exactly with the performance of a 
final and optimized implementation. Nevertheless, it is not 
the same gap we can observe between simulation results and 
real implementation results. In simulation it is very difficult to 
estimate how far a model is from reality and the exact impact 
it has on the performance results. Using Prawn, an estimation 
(even rough) can be deduced from the observed overhead. 

Unlike existing implementation tools, Prawn provides a 
general, simple, concise, yet sufficient set of functions for a 
wide range of high-level algorithms, as well as an API that 
shields the designer from low-level implementation details. 
Through several case studies, we showcased the use of Prawn 
in the context of a wide range of network protocols. But 
the possibilities of Prawn are not restricted to the examples 
given in this paper. Other experiments where Prawn can 
be useful include: evaluating existing protocols for wired 
networks in the wireless context, implementing new routing 
protocols, testing overlay approaches in wireless multi-hop 
networks, evaluating distributed security algorithms, testing 
new naming mechanisms over IP, testing incentive mecha- 
nisms for communities, implementing localization algorithms, 
measuring wireless connectivity in both indoor and outdoor 
scenarios, evaluating peer-to-peer algorithms, testing oppor- 
tunistic forwarding mechanisms. 

We hope our work will provide a starting point for an 
improved design methodology as prototyping provides both 
easy and accurate evaluation of wireless protocols and services 



under real conditions. This paper has demonstrated that this 
is feasible - Prawn is a fully-functional tool that responds 
to the needs of early protocol evaluation. Finally, we expect 
that Prawns simplicity will allow researchers to adopt it. To 
help this becoming true, ongoing work includes adding new 
prototyping facilities, releasing a Java version of the Prawn 
Library, and porting Prawn to other operating systems such as 
FreeBSD and Windows. 
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